Messaging systems that provide voice and fax messaging capabilities are well known. One example of such a messaging system is the Network Applications Platform commercially available from UNISYS Corporation (“the NAP system”). The NAP system is a configuration of hardware and software that provides data and voice processing capabilities through applications running on an enterprise server. The NAP system provides the interface between these applications, called network applications, and a telephone network. A voicemail application is an example of a network application that runs on the NAP platform. The voicemail application determines how calls to the messaging system are handled, what prompts are played to callers, and which features are available. Presently, the NAP is implemented on selected UNISYS A Series and ClearPath HMP NX computer systems running the MCP operating system.
Generally, the NAP platform interfaces to a telephone network through a Network Interface Unit (NIU). Current NAP systems utilize a NIU available from Unisys Corporation, called the Telephony Services Platform (TSP). Generally, the TSP comprises a MultiBus bus architecture (e.g. IEEE 1296 MultiBus) that connects a variety of special purpose printed circuit boards that provide interfaces to the host computer system on which the NAP is implemented and to the telephone network to which the TSP is connected.
In greater detail, FIG. 1 shows a system diagram of a prior art messaging system 100 based on the Unisys NAP architecture. As shown, the system 100 comprises host computer 110 that implements the NAP messaging platform 115, a network interface unit (NIU) 140, which in this example is the Unisys TSP, public switched telephone network 155, and telephone based subscribers 165. Network applications 120 and 125, which may be voice mail applications or any other application that provides telephony related services, run on the NAP platform 115 and cooperate with message store 130.
As shown, the NIU 140, which in this example comprises a Unisys TSP, contains a series of interfaces, interface 1 (INT1), interface 2 (INT2), and interface 3 (INT3). One interface, such as INT1, interfaces the NIU 140 to the NAP platform 115 on the host computer 110. Communication between INT1 and NAP platform 115 is via a Small Computer Systems Interface (SCSI) bus 135. Others of the interfaces, such as INT2 and INT3, interface NIU 140 to PSTN 155. In the current TSP design, interfaces such as INT1, INT2, and INT3 are implemented on printed circuit boards housed within the NIU that can communicate with each other via a common bus 145. Bus 145 implements the MultiBus (IEEE 1296) open bus standard protocol.
In operation, telephone based subscribers 165 may request processing performed by network application 120 or 125, or alternatively, access data from message store 130. The request is transmitted from telephone-based subscriber 165 through PSTN 155 to NIU 140. At NIU 140, the proper interface (i.e. INT1, INT2, or INT3) may route the request to messaging platform 115 of host computer 110 running network applications 120 and 125. Similarly, requested processed data may be communicated back to telephone-based subscribers using this data path.
FIG. 1A is a block diagram providing additional details of the Unisys TSP that implements the NIU 140 in FIG. 1. As shown, interfaces INT2, INT3 are each implemented in the TSP 140 by a Primary Rate Interface Module (PRIM) 140-1, of which there can be many in any given TSP. Interface INT1 is implemented by a PDP4 Card. Each PRIM 140-1 interfaces a set of (e.g., 24 or 32) telephone circuits to the PDP4 card. In addition, one PRIM 140-1a is dedicated to signaling, and communicates with the PDP4 Card's Signaling Manager 140-2a, which in turn communicates with a Host Management Services (HMS) module 140-2b. The HMS module 140-2b communicates with a Cache Manager 140-2c and a Host Interface module 140-2d. The overall function of the TSP 140 is to logically map a plurality of telephone circuits (e.g., 24 or 32 telephone circuits per PRIM) to a NAP host (e.g., host 110 of FIG. 1).
Briefly, an SS7 packet received at a PRIM is routed to the Signaling Manager 140-2a, which is the SS7 User Part (SS7 level 4). The Signaling Manager converts the SS7 packet to a proprietary message that is ultimately received by the host 110. Before sending the message to the host, the HMS module 140-2b selects the host (there can be more than one host connected to a given TSP).
Thus, the components of a TSP 140 may be summarized as follows:                PRIM (Primary Rate Interface module) 140-1: The TSP PRIM module is used to send voice or receive voice from the network upon direction from the NAP 115        Signaling Manager 140-2a: The Signaling Manager is used to communicate to the network using a country specific protocol such as SS7 or ISDN. It also communicates to the NAP 115 for circuit maintenance and for call control.        HMS (Host Management Services module) 140-2b: The TSP HMS module is used to centralize the TSP's handling of the shared TSP functionality described in the aforementioned co-pending patent application Ser. No. 09/307,014, entitled “Inter-System Call Transfer”. It insulates the rest of the TSP from the mechanics of switching calls from one host to another. It communicates to the NAP 115 to transfer calls and to configure the shared TSP environment. All TSP message traffic is routed through the HMS module.        CM (Cache Manager) 140-2c: The TSP CM module is used to provide a high speed buffering of commonly used voice messages to reduce demand on the NAP 115.        HIP (Host Interface Processor) 140-2d: The HIP board is used to communicate to the operating system of the host computer 110 using a SCSI bus to transfer and receive buffers of data between the NAP 115 and TSP. It enforces a protocol on the TSP to collect messages in an efficient manner to transmit to the host 110 and similarly breaks apart buffers from the host into messages that can be processed by other TSP modules.        
Thus, as shown, the TSP 140 is connected to certain “ports” of the telephone network 155. A call coming into a given port is received by the TSP connected to that port. Specifically, a call comes into a PRIM board in the TSP, and the Signaling Manager on the PDP card of that TSP routes the call to the Host Management Services (HMS) module 140-2b. The call comes in on a reserved signaling channel 140-1a of the PRIM and is immediately transferred to the Signaling Manager 140-2a on the PDP board. The signaling manager reformats the call packet and gives it to the HMS module 140-2b, which in turn gives it to the Host Interface Module 140-2d. The Host Interface Module 140-2d places the call on the SCSI bus 135. The NAP 115 takes the call from the SCSI bus, creates a call record, interrogates a database information in memory to obtain the necessary information to route the call to the proper network application 120, 125, and then queues the call to an application interface module (AIM) (not shown). The AIM dequeues the call and gives it to the specified network application 120, 125.
Although current messaging platforms provide a number of media processing features, such features are generally processed on the host computer of the messaging platform wasting valuable processing resources and requiring considerable time to process media. Furthermore, although current messaging platforms allow for the ability to offload such media processing to more efficient computing platforms for processing, such systems and methods are in themselves inefficient often requiring specialized hardware and/or software configurations. The rigidity of current messaging platforms to offload processing renders media processing and arduous task at best. The burdens of media processing are most felt when trying to perform streaming of Web data (e.g. communicating e-mail messages to a voice mail box of a messaging platform) from external networks. Web data, by its nature, can be large and cumbersome requiring extensive processing. As such, current messaging platforms (even ones that offload processing) are not equipped to best process Web type data.
From the foregoing it is appreciated that there exists a need for systems and methods that provide efficient processing of media data.